Fix release publish: reconstruct native artifact paths#79
Merged
Conversation
The publish job assumed downloaded native artifacts kept their full simdjson-native/build-*/ paths, but actions/upload-artifact roots each artifact at the least-common-ancestor of its paths: the simdjson-native/ prefix is stripped from multi-file artifacts and single-file artifacts collapse to a bare filename. With download-artifact merge-multiple into the repo root the Android .so files landed at build-android-*/ (so the copy step failed with "No such file"), and the JNI/KN libraries collided at the repo root, invisible to the Gradle publish. Download each artifact into its own directory and reconstruct the exact tree the publish expects. Host-native libraries (macos-arm64 JNI, macOS/iOS Kotlin/Native .a) are rebuilt on the runner, so only the cross-compiled libraries are staged.
There was a problem hiding this comment.
Pull request overview
This PR fixes the Maven Central release workflow by avoiding artifact path collisions/flattening from actions/upload-artifact, and explicitly staging downloaded native libraries back into the repository layout that the Gradle publish expects.
Changes:
- Download all native artifacts into a dedicated
artifacts/directory (no merge into repo root). - Add a
stage()helper to reconstruct expected repo-relative native library paths before publishing. - Stage only cross-compiled natives (Linux/Windows JNI, Linux KN
.a, Android.sos), relying on the macOS runner to rebuild host-native outputs.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
0.1.0release publish failed at Copy Android natives to jniLibs:Root cause: the publish job assumed downloaded native artifacts kept their full
simdjson-native/build-*/…repo-relative paths. Butactions/upload-artifactroots each artifact at the least-common-ancestor of itspathentries:native-android,native-kn-ios) lose thesimdjson-native/prefix → keep onlybuild-*/lib;With
download-artifact --merge-multipleinto the repo root, the Android.sos landed atbuild-android-*/…(so thecpfailed — the observed error), and the JNI/KN libraries collided at the repo root (twolibsimdjson_jni.so, twolibsimdjson_c.a), invisible to Gradle. Even after fixing Android,Publishwould then fail the-Psimdjson.allTargets=truerequireAllNativescheck for linux-x64/linux-arm64/windows, and the linuxX64 cinterop would miss its static.a.Fix
Download each artifact into its own directory (
path: artifacts, nomerge-multiple) and reconstruct the exact tree the publish expects via an explicitstage()helper. Only cross-compiled libraries are staged (linux-x64/linux-arm64/windows JNI, linux-x64 KN.a, both Android ABIs →jniLibs/); host-native libraries (macos-arm64 JNI, macOS/iOS.a) are rebuilt on the runner.Verification
Simulated the new
stage()steps against the real 8 artifacts from the failed run — all 6 required destination paths are reconstructed correctly; YAML validated. The fullpublishToMavenCentralitself can't be run locally (needs Sonatype/signing secrets), so credential/POM-level issues, if any, would only surface on a real run.